(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 

International Bureau 

(43) International Publication Date 
21 November 2002 (21.11.2002) 




PCT 



i eiiii inum Ei imu mil mi i n nt uhi iiiii nni nm uni mi iiiiid uu ui mi 

(10) International Publication Number 

WO 02/093294 A2 



(51) International Patent Classification 7 : G06F 

(21) International Application Number: PCT/US02/13756 

(22) International Filing Date: 1 May 2002 (01.05.2002) 

(25) Filing Language: English 

(26) Publication Language: English 



(30) Priority Data: 
60/291,199 
10/105,517 



15 May 2001 (15.05.2001) US 
25 March 2002 (25.03.2002) US 



(71) Applicant: CURRENEX, INC. [US/US]; 3565 Haven 
Ave., Menlo Park, CA 94025 (US). 

(72) Inventors: KLECKNER, James; 1855 Cowper St., Palo 
Alto, CA 94301 (US). BENTON, Renee; 4490 Palmdale 
St., Union city, CA 94598 (US). TRAN, Minh; 748 Page 
St., Apt. 4, San Francisco, CA 94117 (US). 



(74) Agent: PARK, Richard; 508 2nd Street, Suite 201, Davis, 
CA 95616 (US). 

(81) Designated States (national): AE, AG, AL, AM, AT, AU, 
AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CO, CR, CU, 
CZ, DE, DK, DM, DZ, EC, EE, ES, FI, GB, GD, GE, GH, 
GM, HR, HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, 
LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, 
MX, MZ, NO, NZ, OM, PH, PL, PT, RO, RU, SD, SE, SG, 
SI, SK, SL, TJ, TM, TN, TR, TT, TZ, UA, UG, UZ, VN, 
YU, ZA, ZM, ZW. 

(84) Designated States (regional): ARIPO patent (GH, GM, 
KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZM, ZW), 
Eurasian patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), 
European patent (AT, BE, CH, CY, DE, DK, ES, FL, FR, 
GB, GR, BB, IT, LU, MC, NL, PT, SE, TR), OAPI patent 
(BF, BJ, CF, CG, CI, CM, GA, GN, GQ, GW, ML, MR, 
NE, SN, TD, TG). 



[Continued on next page J 



(54) Title: METHOD AND APPARATUS FOR AUTOMATING THE PROCESS OF SETTLING FINANCIAL TRANSACTIONS 



Jill Q START ^ 



< 
On 

m 

o 



RECEIVE VAUD TRADE RECORDER) 1202 



m e 



CX OPTIONALLY FILTERS BAD REQUESTS 1203 | 



SEND TR TO CLEARING AGENT 1 (CA1) AND 
CLEARING AGENT 2 (CA2) TELLING CA1 AND 

CA2 TO MOVE FUNDS INTO RESPECTIVE 
ESCROW ACCOUNTS (OR REQUEST TO NOLO 
OF FUNDS IN SOURCE ACCOUNTS) 



2VAUa 



CA1 AND CA2 VALIDATE TR AND 
INSTRUCTIONS AND SEND RESULT TO CX 
1206 




CA1 AND CA2 ATTEMPT TO MOVE FUNDS 
WTO ESCROW ACCOUNTS (OR REQUEST 
HOLD OF FUNDS IN SOURCE ACCOUNTS) 
1208 



SUCCESS? 
'(2 SIGNED USGS)^ 
1210 



INSTRUCT CA1 AND CA2 TO PAY FUNDS 
FROM ESCROW ACCOUNTS TO RECEIVERS 
BY PASSING MESSAGES 1218 





UPON NOTIFICATION OF RECEIPT OF 2 
SIGNED INSTRUCTIONS, CX 

-NOTIFIES PARTIES 

-ALLOWS CA1 AND CA2 TO EFFECT 

FUNDS TRANSFERS 
UPON RECEIVING A 'PAYMENT DONE" 
MESSAGE FROM CA1 AND CA2, CX 
COMMITS TRANSACTION 
1220 


R0LLBACWABORT TRANSACTION j 
1212 


T 


REPORT FAILURE TO PARTIES f 
' ' 1214 I 




RETRY IF APPROPRIATE ft 
1218 | 




1 .( EN ° \ .- 



(57) Abstract: One embodiment of the present invention pro- 
vides a system for automatically settling a financial transac- 
tion. This system operates by receiving a trade record speci- 
fying previously-agreed-to details of the financial transaction 
between a first party and a second party. This trade record in- 
cludes settlement instructions specifying a transfer of a first 
financial instrument belonging to the first party into a second 
party destination account belonging to the second party. It also 
includes a second digital signature created by digitally signing 
at least a portion of the trade record, including the settlement 
instructions, with a second private key belonging to the second 
party. Upon receiving this trade record, the system attempts to 
ensure that funds are available to complete the financial trans- 
action. If funds can be ensured, the system causes the first fi- 
nancial instrument to be transferred into the second party des- 
tination account on condition that the second digital signature 
can be verified using a corresponding second public key. 
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METHOD AND APPARATUS FOR AUTOMATING 
THE PROCESS OF SETTLING FINANCIAL 
TRANSACTIONS 

5 

Inventors: James E. Kleckner, Renee D. Benton, and Minh T. Tran 

10 BACKGROUND 

Field of the Invention 

The present invention relates to computer-based systems for trading financial 
instruments. More specifically, the present invention relates to a method and an 
1 5 apparatus that uses digital signatures to automate the process of settling financial 
transactions, such as foreign exchange transactions. 

Related Art 

The foreign exchange market is the largest and most liquid market in the 
20 world. In 1998, the Federal Reserve Bank of New York estimated, that daily turnover 
was approximately $1.5 trillion. 

Unlike stocks, which are market-traded, foreign exchange is primarily an 
over-the-counter market. There is no such thing as a "price" for a particular 
transaction. Rather, each dealer, bank, broker, or other trading source, provides their 
25 own rate for each transaction. 

The trading and settlement processes for a typical foreign exchange 
transaction are illustrated in FIG. 1. A trader 102, working on behalf of a corporation 
or other entity, makes a quote request 106 to a trader 104, working on behalf of a 
bank. In response to this quote request, trader 104 makes a quote 108 proposing a rate 
30 for the transaction. 
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Trader 102 accepts the quote by sending an acceptance message to trader 104, 
in which case trader 104 typically sends an acknowledgement message 1 12 back to 
trader 102. 

Note that the communication process outlined above typically takes place over 
5 the telephone or via facsimile. 

After traders 1 02 and 1 04 agree to the terms of the transaction, trader 1 02 
communicates trade information to settlement clerk 1 18, who works on behalf of the 
same organization as trader 102. Similarly, trader 104 communicates trade 
information 1 16 to settlement clerk 120, who works on behalf of the same 
10 organization as trader 104. 

Settlement clerks 118 and 120 are responsible for actually causing funds to be 
transferred between accounts of the two organizations involved in the trade. Before 
doing so, settlement clerks 118 and 120 communicate and confirm settlement 
information 122 with each other. This settlement information 122 confirms the terms 
15 of the trade, and additionally specifies the accounts between which funds are to be 
transferred. 

Note that settlement clerks i 18 and 120 typically communicate settlement 
information 122 via telephone or facsimile. In some cases, this settlement 
information is communicated through a third party payment matching system 128. 

20 After the settlement information is communicated, and if the terms of the deal 

are in agreement, settlement clerk 1 1 8 communicates with funds transfer agent 126, 
who actually transfers the funds. Similarly, settlement clerk 120 communicates with 
funds transfer agent 124 to transfer funds in the reverse direction. 

Note that the separation of roles between trading and settlement provides a 

25 measure of protection against fraud because collusion between a trader and a 
settlement clerk is required to perpetrate most types of fraud. However, this 
protection has a price, because the many manual communications, validations, and 
confirmations involved in the role-based trading and settlement processes are time- 
consuming and expensive. 
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Also note that the trade terms and settlement instructions are typically entered 
manually on both sides of the transaction. Consequently, the trade terms and 
settlement instructions are often not entered in the same way, and may not match. 
Even if the trade terms and settlement instructions are entered properly, netting and 
5 aggregation can cause trades not to match. If trades do not match, a great amount of 
additional work is required to sort out inconsistencies. 

What is needed is a method and an apparatus for facilitating trading and 
settlement of financial instruments, such as currencies, without the time-consuming 
manual processes involved in existing trading, settlement, and confirmation processes. 

10 Note that a certain amount of risk is inherent in the settlement process. During 

a foreign exchange transaction, funds are typically transferred from a first party to a 
second party in exchange for funds being transferred from the second party to the first 
party. If the transfer to the second party fails because the first party lacks sufficient 
funds, it is possible for second party to transfer funds to the first party without 

15 receiving funds in return. 

Since these transfers can be very large (possibly hundreds of millions or 
billions of dollars), the failed transfer may cause the second party to lack funds to 
honor other transactions. This problem can rapidly spread to other parties until the 
trading system grinds to a halt. 

20 Hence, what is needed is a method and an apparatus for reducing settlement 

risk during the process of settling financial transactions. 

SUMMARY 

One embodiment of the present invention provides a system for automatically 
25 settling a financial transaction. This system operates by receiving a trade record 
specifying previously-agreed-to details of the financial transaction between a first 
party and a second party. This trade record includes settlement instructions 
specifying a transfer of a first financial instrument belonging to the first party into a 
second party destination account belonging to the second party. It also includes a 
30 second digital signature created by digitally signing at least a portion of the trade 
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record, including the settlement instructions, with a second private key belonging to 
the second party. Upon receiving this trade record, the system attempts to ensure that 
funds are available to complete the financial transaction. If funds can be ensured, the 
system causes the first financial instrument to be transferred into the second party 
5 destination account on condition that the second digital signature can be verified using 
a corresponding second public key. 

In one embodiment of the present invention, the settlement instructions 
additionally specify a first party source account from which the first financial 
instrument is to be transferred. In this embodiment, the trade record additionally 
10 includes a first digital signature created by digitally signing at least a portion of the 
trade record including the settlement instructions with a first private key belonging to 
the first party. 

In a variation on this embodiment, ensuring that funds are available to 
complete the financial transaction involves causing a hold to be placed on the first 
1 5 financial instrument within the first party source account, so that the first financial 
instrument is ensured to be available to be transferred into the second party 
destination account. 

In one embodiment of the present invention, causing the first transfer involves 
communicating at least a portion of the trade record, including the settlement 
20 instructions and the second digital signature, to a first clearing agent so that the first 
clearing agent can use the corresponding second public key to verify that the second 
digital signature was created using the second private key prior to transferring the first 
financial instrument into the second party destination account. 

In one embodiment of the present invention, the settlement instructions 
25 additionally specify a transfer of a second financial instrument to a first party 
destination account. In this embodiment, the trade record includes a first digital 
signature created by digitally signing at least a portion of the trade record including 
the settlement instructions using a first private key belonging to the first party. 

In a variation in this embodiment, causing the transfer of the second financial 
30 instrument into the first party destination account involves communicating at least a 
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portion of the trade record, including the settlement instructions and the first digital 
signature, to a second clearing agent, so that the second clearing agent can use a first 
public key to verify that the first digital signature was created using the first private 
key prior to transferring the second financial instrument into the first party destination 
5 account. 

In one embodiment of the present invention, ensuring that funds are available 
to complete the financial transaction involves causing the transfer of the first financial 
instrument from the first party into a first escrow account, so that the first financial 
instrument is available to be transferred into the second party destination account. 

10 In one embodiment of the present invention, ensuring that funds are available 

to complete the financial transaction involves verifying a payment guarantee 
contained within the trade record, the payment guarantee having been previously 
provided by the first party. This payment guarantee ensures that the first financial 
instrument is available to be transferred to the second party destination account. In a 

1 5 variation on this embodiment, the payment guarantee includes a record that a hold has 
been placed on the first financial instrument within a first source account. In another 
variation on this embodiment, the payment guarantee includes the first financial 
instrument in digital form. 

In a variation on this embodiment, the system additionally records the 

20 settlement operation in a database. 

In a variation on this embodiment, the system additionally validates an identity 
of the first party by using a public key of a certification authority to verify that a 
certificate containing the public key of the first party was signed by a corresponding 
private key belonging to the certification authority. This signing by the certification 

25 authority indicates that the certification authority has verified the identity of the first 
party. 

In a variation on this embodiment, the financial transaction involves foreign 
exchange, and the trade record includes: a trade identifier; a trade date; an identifier 
for a first currency; a first currency amount; an identifier for a first organization 
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providing the first currency; an identifier for a second currency; a second currency 
amount; and an identifier for a second organization providing the second currency. 

BRIEF DESCRIPTION OF THE FIGURES 

5 FIG. 1 illustrates typical trading and settlement processes. 

FIG. 2 illustrates an exchange that facilitates automated trading and settlement 
in accordance with an embodiment of the present invention. 

FIG. 3 illustrates how credentials and permissions are granted in accordance 
with an embodiment of the present invention. 
10 FIG. 4 is a flow chart illustrating the process of obtaining a credential from a 

certification authority in accordance with an embodiment of the present invention. 

FIG. 5A is a flow chart illustrating how an exchange security officer is 
authorized in accordance with an embodiment of the present invention. 

FIG. 5B is a flow chart illustrating how a security officer obtains authority to 
1 5 grant permissions in accordance with an embodiment of the present invention. 

FIG. 6 is a flow chart illustrating the process of obtaining a permission from a 
security officer in accordance with an embodiment of the present invention. 

FIG. 7 is a flow chart illustrating the process of facilitating a trade in 
accordance with an embodiment of the present invention. 
20 FIG. 8 is a flow chart illustrating the process of settling a trade in accordance 

with an embodiment of the present invention. 

FIG. 9 illustrates the structure of a trade record in accordance with an 
embodiment of the present invention. 

FIG. 10 is a flow chart illustrating the process of establishing a policy for a 
25 trade and/or amendment approvals in accordance with an embodiment of the present 
invention. 

FIG. 1 1 illustrates entities involved in the settlement process in accordance 
with an embodiment of the present invention. 

FIG. 12 is a flow chart illustrating the settlement process in accordance with 
30 an embodiment of the present invention. 
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FIG. 13 is a flow chart illustrating the settlement process in accordance with 
another embodiment of the present invention. 

DETAILED DESCRIPTION 

5 The following description is presented to enable any person skilled in the art 

to make and use the invention, and is provided in the context of a particular 
application and its requirements. Various modifications to the disclosed embodiments 
will be readily apparent to those skilled in the art, and the general principles defined 
herein may be applied to other embodiments and applications without departing from 

10 the spirit and scope of the present invention. Thus, the present invention is not 
intended to be limited to the embodiments shown, but is to be accorded the widest 
scope consistent with the principles and features disclosed herein. 

The data structures and code described in this detailed description are typically 
stored on a computer readable storage medium, which may be any device or medium 

1 5 that can store code and/or data for use by a computer system. This includes, but is not 
limited to, magnetic and optical storage devices such as disk drives, magnetic tape, 
CDs (compact discs) and DVDs (digital versatile discs or digital video discs), and 
computer instruction signals embodied in a transmission medium (with or without a 
carrier wave upon which the signals are modulated). For example, the transmission 

20 medium may include a communications network, such as the Internet. 

Exchange System 

FIG. 2 illustrates an exchange 200 that facilitates automated trading and 
settlement in accordance with an embodiment of the present invention. Exchange 200 

25 facilitates trades between treasury systems 202-204 and trading systems 208-2 10. 
Exchange 200 can additionally be coupled to a number of other exchanges 206-207. 
Note that exchange 200, treasury systems 202-204 and trading systems 208-2 10 run 
on computer systems. These computer systems can generally include any type of 
computer system, including, but not limited to, a computer system based on a 

30 microprocessor, a mainframe computer, a digital signal processor, a portable 
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computing device, a personal organizer, a device controller, and a computational 
engine within an appliance. 

Also note that linkages show in FIG. 2 pass across one or more computer 
networks (not shown). These networks generally include any type of wire or wireless 
5 communication channel capable of coupling together computing nodes. This 
includes, but is not limited to, a local area network, a wide area network, or a 
combination of networks. In one embodiment of the present invention, the network 
includes the Internet. 

Treasury systems 202-204 generally belong to organizations requiring foreign 
1 0 exchange services, such as corporations, funds or non-governmental organizations 
(NGOs) but could also include banks requesting trades. Hence, treasury systems 202- 
204 generally request quotes for from trading systems 208-210, and accept quotes 
from trading systems 208-210. 

Trading systems 208-210 generally belong to banks providing foreign 
15 exchange services but could include other organizations that choose to act as quote 
makers. Hence, trading systems 208-210 generally receive quote requests from 
treasury systems 202-204, and make quotes to be accepted by treasury systems 202- 
204. 

Treasury systems 202-204 are coupled to one or more funds transfer agents, 
20 such as funds transfer agent 220, which carry out instructions to actually transfer 
funds between accounts. Similarly, trading systems 208-2 10 are coupled to one or 
more funds transfer agents, such as funds transfer agent 221 . Note that funds transfer 
agents 220 and 221 may be the same funds transfer agent. 

Exchange 200 communicates secure, authenticated quote requests, quotes and 
25 quote acceptances between treasury systems 202-204 and trading systems 208-210. 
Exchange 200 also facilitates communication of settlement instructions between 
treasury systems 202-204 and trading systems 208-210. These functions are 
described in more detail with reference to FIGs. 3-9 below. 

Note that exchange 200 can additionally be coupled to exchanges 206-207 to 
30 facilitate cross-exchange transactions. 
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Relationships Between Actors and Organizations 

FIG. 3 illustrates the relationships and interactions of the involved actors and 
5 organizations in accordance with an embodiment of the present invention. In FIG. 3, 
organization 302 trades with organization 304 through exchange 200. Certification 
authority 320 often includes an independent entity, such as an accounting firm or an 
independent certification authority, that verifies the identity of users and grants 
credentials for use by various actors belonging to organizations 302-304 and to 
1 0 exchange organization 306. 

More specifically, organization 302 includes treasury system 202, which 
communicates with exchange 200. Treasury system 202 operates under control of 
user 3 10, such as a front office trader, who receives permissions from a local security 
officer 312, who also is associated with organization 302. Organization 302 also 
1 5 includes a settlement clerk 311, who is responsible for settling trades made by user 
310. 

Similarly, organization 304 includes trading system 208, which communicates 
with exchange 200. Trading system 208 operates under control of user 318, who 
receives permissions from a local security officer 316, who is also associated with 

20 organization 304. Organization 304 also includes a settlement clerk 319, who is 
responsible for settling trades made by user 318. 

Exchange organization 306 includes exchange 200 as well as permission 
security officer 314, who confers permission granting authority to local security 
officers 3 1 2 and 3 1 6 in conjunction with CA 320 through the process outlined in FIG. 

25 5 below. Note that exchange 200 is coupled to a database 301, which contains 

permission table 305. Permission table 305 contains permissions for users 310 and 
3 1 8, security officers 3 1 2 and 3 1 6, and settlement clerks 3 1 1 and 3 1 9. 

All of the above-described entities receive credentials from independent 
certification authority (CA) 320, which grants credentials to users 310 and 318, 

30 security officers 3 1 2, 3 14 and 3 1 6, and settlement clerks 3 1 1 and 319. This credential 
granting process is described below with reference to FIG. 4. 
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During operation of the system illustrated in FIG. 3, CA 320 generates 
credentials 330-334 that are used by actors, such users 310 and 318, security officers 
31 2, 3 14 and 3 1 6 and settlement clerks 3 1 1 and 3 1 9 to validate identities. 

In addition to validating identities, the system illustrated in FIG. 3 validates 
5 permissions to perform operations, such as trading and settling trades, and can embed 
information into the trading records so that these validations can be performed 
independently by organizations 302 and 304. Permission security officer 314, who 
belongs to exchange organization 306, confers permission granting authority on 
security officers 312 and 316 belonging to organizations 302 and 304, respectively. 

10 Security officers 312 and 3 16 in turn grant trading permissions 340 and 341 to users 
310 and 318, respectively. Security officers 312 and 316 can also grant settlement 
permissions 342 and 343 to settlement clerks 31 1 and 319, respectively. Note that 
users 310 and 318 require both permissions and credentials in order to perform 
actions, such as trading and settling trades. 

15 Note that in the present invention, permissions for various actors are stored 

within a central permission table 305, instead of being embedded within certificate 
chains in credentials of the actors. Table 305 correlates permission additions, 
subtractions and modifications to provide an up to date unified view of all user 
authorizations in the system. Table 305 stores the signed permission request records 

20 that can be used to determine the entity (security officer) that granted the particular 
permission to the individual. When a user's authorizations are queried, permission 
table 305 returns a signed response containing the collection of signed permission 
requests associated with the user along with a timestamp value to validate the user's 
permissions at the time of the query. Since permission queries can be performed 

25 concurrently with permission updates, the system defines a minimum quiescent period 
(typically < 10 seconds) which delays the recognition of permission changes to allow 
queries to complete in a consistent state. 

Also note that in one embodiment of the present invention, there exist multiple 
security officers for organization 302, organization 304 and exchange organization 

30 306. In this embodiment, more than one security officer must agree in order to 
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change the privileges of a security officer. This prevents a single security officer 
from unilaterally changing his or her own privileges. The organization 302 or 304 
may also specify that more than one security officer is required to agree to authorize 
permissions of other users as well. 

5 

Process of Bootstrapping Exchange Security Officers 

In order to bootstrap the system, exchange organization 306 must first initiate 
the creation of at least two exchange security officers: a Credential Security Officer 
(CSO) 315 and a Permission Security Officer (PSO) 314. These two security officers 

10 must be independent individuals in order to enforce a separation of duties. Exchange 
organization 306 communicates a schedule to CA 320 identifying these security 
officers within exchange organization 306. The two security officers CSO 3 1 5 and 
PSO 314 may then request and receive credentials 332 from CA 320 following the 
procedure outlined in FIG. 4. 

15 Once the credentials are granted, exchange organization 306 must then initiate 

the creation of permissions for the two security officers. Note that it is desirable that 
"credential creation" and "permission creation" permissions be mutually exclusive to 
maintain separation of duties. Ideally, no single actor in the system should be granted 
both "credential creation" and "permission creation" permission as a safeguard for 

20 fraud. Exchange organization 306 communicates a schedule to CA 320 granting the 
following permissions to the respective security officers: 

Credential Security Officer (CSO) 

• CSO credential creation permission 
25 • PSO credential creation permission 

Permission Security Officer (PSO) 

• CSO permission creation permission 

• PSO permission creation permission 

30 

Once the two initial security officers are successfully bootstrapped with the 
appropriate credentials and permissions, additional exchange CSOs and PSOs can be 
added into the system. The original CSO 3 1 5 can first create and approve a new 
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CSO. The original PSO 314 may then confer CSO permissions upon the new CSO, 
At that point, the newly created CSO is functionally identical to the bootstrapped 
CSO. Similarly an additional PSO may be created within the system. Exchange 
organization 305 may wish to establish more restrictive guidelines concerning the 
5 creation of CSOs and PSOs requiring the approval to multiple CSOs or PSOs 
respectively. In such instances, the bootstrap process must be augmented by the 
appropriate number of security officers to ensure the guidelines are met. 



Process of Bootstrapping Member Organization Security Officers 
1 0 Independent organizations that may wish to join the system can request the 

appropriate credentials and permissions for their own CSO and PSO representatives 
who then have the authorization to grant credentials and permissions for users within 
their own organization. Member organization 302 communicates a schedule to a CSO 
in exchange organization 306 identifying these designated security officers within 
1 5 member organization 302. Once these credentials are requested and received, the 
member organization can communicate a schedule of permissions for a PSO in 
exchange organization 306 granting the following permissions: 

Credential Security Officer (CSO) 
20 • CSO credential creation permission 

• PSO credential creation permission 

• User credential creation permission 

Permission Security Officer (PSO) 
25 • CSO permission creation permission 

• PSO permission creation permission 

• Trading permission creation permission 

• Settlement permission creation permission 

30 Additional permissions may be defined as required. Certain permissions such as the 
trading permission and settlement permission should ideally be identified as mutually 
exclusive in order to eliminate the possibility of a single actor committing fraud 
within the system. 

Once the two initial security officers are successfully bootstrapped with the 
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appropriate credentials and permissions, additional organization CSOs and PSOs can 
be added into the system as well as organization users that will be conducting trades 
and settlements. This distributed mechanism allows the member organizations to 
independently manage their authentication and authorization functions according to 
5 their internal policies and procedures. 

Process of Obtaining a Credential 

FIG. 4 is a flow chart illustrating the process of obtaining a credential 330 for 
a user 3 10 in accordance with an embodiment of the present invention. Note that in 

10 one embodiment of the invention, this credential is implemented as a digital 
certificate. The process starts when user 310 requests a credential 330 from an 
organization CSO. In response to the request, CSO instructs user 3 10 to contact CA 
320 (step 404). The organizational CSO additionally instructs CA 320 to issue a 
credential for user 310 (step 406). 

1 5 Next, user 3 1 0 constructs a public key/private key pair (step 408) through their 

browser or a hardware cryptographic token, and then sends the newly created public 
key along with a request for a credential to CA 320 (step 410). 

CA 320 then verifies the authenticity of the request (step 412). This process 
involves determining if a CSO has instructed CA 320 to issue the credential 330. It 

20 also involves performing some type of manual or automated identity check on user 
310. For example, the check can involve a database lookup of information on user 
310, an interview with user 310, a telephone call to user 310 or a facsimile 
communication with user 310. In one embodiment, a unique randomly generated 
personal identification number (PIN) is communicated by the CSO to both user 310 

25 and CA 320 that identifies to CA 320 this request for a credential is valid. This PIN 
can only be used once to request signing of the credential by CA 320. The user's 
corresponding PSO will authenticate requests for permission by signing permissions 
in the permission table 305 (see below). 

If the request is properly verified, CA 320 signs credential 330 with a private 

30 key belonging to CA 320 (step 414), and returns credential 330 to user 310 and to CX 
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200 (step 416). CX 200 then places the new credential 330 for user 3 1 0 in its 
database 301 (step 418). Note that credential 330 is signed by CA 320 and includes a 
public key for user 3 1 0. 

5 Process of Validating a Credential 

Throughout the trade creation, amendment and settlement process, the actors 
in the system including users 310 and 318, security officers 312, 314 and 316, and 
settlement clerks 3 1 1 and 3 19 may require validation of the credentials of fellow 
actors with whom they are interacting within the system. In one embodiment of the 

10 invention, the permission table 305 acts as the system of record for credential validity. 
The status of credentials 330-334 may be confirmed as valid by querying the 
permission table. If the credential presented for validation matches a credential stored 
in permission table 305, the system returns a signed response containing a 
timestamped credential record that confirms the validity of the credential. If the 

1 5 credential is not found in permission table 305, the system returns a signed, 

timestamped response that indicates that the queried credential was not valid. In one 
embodiment of the invention, actors may query the validity of a credential by 
checking if the digital certificate is listed with a revoked status in a Certificate 
Revocation List (CRL) published by certification authority 320. An alternate method 

20 would be to send an Online Certificate Status Protocol request (OCSP) to certification 
authority 320 to query the real-time status of the digital certificate. 

If a credential does not successfully verify, ideally the actor should not be 
permitted to continue their participation within the system and their requested action 
should be blocked from further execution. 

25 

Process of Obtaining a Permission 

FIG. 6 is a flow chart illustrating the process of obtaining a permission 340 
from a organization PSO for a user 3 10 in accordance with an embodiment of the 
present invention. User 310 first sends a request to a PSO to obtain a permission, 
30 such as the permission to trade (step 602). The request contains information 
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including the user's credential and a unique string that identifies the permission that 
the user is requesting and is signed by the user's private key. The PSO then validates 
the identity of user 310 by retrieving the public key for user 3 1 0 from the permission 
table 305 and using the public key to validate the signature of the request. If the 
5 identity validates, the PSO determines whether to grant the permission based upon 
authorization rules and processes defined by organization 302 (step 606). If the 
permission is to be granted, the PSO signs the request with a private key belonging to 
the PSO. The system performs an internal query of permission table 305 to verify that 
the PSO has the appropriate permission to grant permissions to user 3 10 and if the 

10 query is successful, the request is stored within permission table 305 (step 608). Steps 
604 through 608 are then repeated for each signature required by the authorization 
policy of the organization 302. Note that for some users, such as security officers, 
organizations may establish policies that may require signatures from multiple 
security officers in order to add/modify/remove their permission records. This 

1 5 prevents a single security officer from unilaterally authorizing powers for himself. 
Also note that requiring multiple signatures generally increases the security of the 
system because multiple actors are required to collude in order to improperly 
authorize additional powers for a user. 

The PSO then sfcnds an acknowledgement to user 3 10 to complete the process 

20 (step 610). 

If the permission is not to be granted, the PSO sends a request denial to user 
310 (step 612). 

Note that permission table 305 contains an entry for each user. This entry 
contains a number of fields indicating various permissions. The entry also stores the 
25 signed timestamped permission requests associated with the permissions that have 
been granted for each user. For example, a given entry for user 310 may include a 
collection of unique string identifying the user's permissions as well as the signed 
permission requests associated with the user. 
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Process of Validating a Permission 

Throughout the trade creation, amendment and settlement process, the actors 
in the system including users 3 1 0 and 3 1 8, security officers 312, 314 and 316, and 
settlement clerks 31 1 and 319 require validation of the permissions of fellow actors 
5 with whom they are interacting within the system. In the present invention, the actors 
can append their relevant permissions to a trade record to validate their authorization 
to perform trading functions. Actors can request a timestamped permission record to 
document this authorization from CX 200. The status of permissions 340, 341, 350 
and 351 can also be confirmed through a query of permission table 305. A query of 
10 the permission table may consist of a credential 330-334 and a permission string. The 
response to a permission query includes the credential, all relevant signed permission 
requests and a timestamp signed by CX 200. 

Process of Facilitating a Trade 

15 FIG. 7 is a flow chart illustrating the process of facilitating a trade in 

accordance with an embodiment of the present invention. This process starts when a 
user 310 creates and digitally signs a quote request, and sends the quote request to CX 
200 (step 702). Note that this quote request can include a list of banks to engage. 

Also note that the term "digitally signing" refers to the process of encrypting 

20 the computed hash value of a message with a private key belonging to a first entity to 
generate a "digital signature". Other entities can then verify that the message was 
signed by the private key belonging to the first entity by decrypting the signature with 
the public key belonging to the first entity and comparing the result to the computed 
hash of the message that the signature was attached to. 

25 Upon receiving the quote request, CX 200 looks up the trading permission for 

user 310 in permission table 305. If the entry in permission table 305 is null (empty), 
CX 200 rejects the quote request. Otherwise, CX 200 appends a timestamped signed 
trading permission for user 3 10 to a trade record containing the quote request (step 
704). CX 200 then sends the trade record to the specified bank users (step 706). 



WO 02/093294 



PCT/US02/13756 



17 

Each bank user 318 who receives the trade record checks the signature on the 
quote request to validate the identity of user 310, and also checks permission 
information in the trade record to verify that user 310 has permission to perform the 
trade (step 708) and that the permission was granted by authorized exchange security 
5 officers. 

If the identity and permission are valid, each interested bank user 31 8 adds a 
price quote to the trade record, signs the appropriate fields (as described with 
reference to FIG. 9) of the trade record, appends the signature, and returns the trade 
record to CX 200 (step 710). 
10 Next, CX 200 receives trade records with quotes from interested bank users 

(step 712). CX 200 then performs checks on the quotes and retrieves trading 
permissions for each interested bank user from permission table 305. If these trading 
permissions are not null, CX 200 appends the permissions to the trade record (step 
714). 

15 When all quotes have been received and the auction time expires, CX 200 

returns a compiled quote record along with the augmented trade record to user 310 
(step 716). Note that although the present example is presented in the context of a 
reverse auction, the present invention can generally be applied to trading and settling 
systems that use any type of pricing mechanism, and is not limited to reverse auctions. 

20 Next, user 310 examines all of the quotes in the compiled quote record, and 

selects one for execution. If a quote is selected, user 3 1 0 tests the signature and 
permissions of the quote. If these are valid, user 3 1 0 signs the portion of the trade 
record with the selected quote, and returns the trade record to CX 200 (step 718). 

Upon receiving the trade record, if no bank user has sent a cancellation prior 

25 to receipt of the user selection, and if the decision time has not expired for user 3 1 0, 
CX 200 records the trade in database 301 . Upon successful commit, CX 200 sends 
the appropriate subset of the trade to the winning bank user, and informs all other 
bank users and user 3 10 of success or failure (step 720). 

Next, bank user 3 1 0 sends the trade record to settlement clerk 3 1 1 within the 

30 same organization 302 to settle the trade (step 722). 
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Process of Settling a Trade 

FIG. 8 is a flow chart illustrating the process of settling a trade in accordance 
with an embodiment of the present invention. The process starts when settlement 
5 clerk 3 1 1 augments the trade record with allocations of funds and physical settlement 
instructions. Settlement clerk 31 1 then signs the related fields of the trade record 
(step 802). Note that if the settlement instructions are default (standing) instructions, 
settlement clerk 3 1 1 may not have to append additional settlement instructions to the 
trade record. Settlement clerk 311 also sends payment instructions to funds transfer 
10 agent 220. 

Next, for each additional approval required in the approval policy for 
organization 302 a digital signature is requested from the appropriate actors and 
recorded within the trade record, and the trade record is then returned to CX 200 (step 
803). 

1 5 Upon receiving the trade record, CX 200 looks up the settlement permission 

for settlement clerk 31 1 . If this permission is not null, CX 200 adds a timestamped 
record of the permission to the trade record (step 804). CX 200 then commits the 
trade record to database 301 (step 806), and sends the trade record to bank settlement 
clerk 319 (step 808). 

20 Upon receiving the trade record, bank settlement clerk 319 checks the 

signatures and settlement permissions of settlement clerk 31 1, and possibly checks 
other signatures and permissions in the trade record. If all are valid, settlement clerk 
319 sends instructions to funds transfer agent 221 to complete the trade (step 810). 
Note in one embodiment of the present invention, bank settlement clerk 319 can 

25 determine if there are enough signatures by performing a query CX 200 to retrieve a 
signed policy record. 



30 



Trade Record Structure 

FIG. 9 illustrates the structure portions of a trade record 900 in accordance 
with an embodiment of the present invention to trade Spot Foreign Currency 
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Exchange (FX). Trade record 900 includes a number of fields, some of which are 
illustrated in FIG. 9. 

These fields include trade ID 903 and amend trade ID 905. These fields are 
used in the amendment process to link which trade record amends which other one. 
5 Note that amend trade ID 905 is null for an original trade that has no amendments. In 
one embodiment of the present invention, the system creates an amending trade in the 
database or communicates one that has the same amend trade ID 905 field as a trade 
record that is already in the database. The system also refuses to make further 
changes to a trade record that has an amending trade record whose amend trade ID 

10 905 field points to it. If a new amendment is made to a previously amended trade, the 
amend trade ID 905 field of the new amendment reflects the value of the trade ID 903 
field of the previously amended trade. In one embodiment of the present invention, 
the trade record may also contain an original trade ID field 907. For new trades, this 
field 907 stores the same value as trade ID field 905. For amended trades, this field 

15 907 stores the trade ID of the original trade that the amendment modifies. If the 
amendment modifies a previous amendment, this field 907 should reference the 
original trade ID. This field can be used to link related trades and amendments to an 
provide an efficient index for trade queries. 

Status field 901 indicates a status of the trade record. For example, the trade 

20 record may have a status of "pending," "valid," "old" or "cancelled pending." 
"Pending" indicates that the record has not yet been agreed upon between the two 
parties to the trade. "Valid" indicates that the trade record has been agreed to between 
the parties is currently in force. "Old" indicates that the trade record has been 
superceded by an amended trade record. "Cancelled pending" indicates that the trade 

25 record was never agreed to, and was superceded by another amended trade record. 
Note that status field 901 is not signed because it is computable from the other trades 
and is added by CX 200 as a convenience for reporting. 

Trade date 902 identifies the date the trade took place, and value date 904 
which identifies the date the currency is to be exchanged. 
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Currency 1 (CCY 1) identifier 906 identifies a first currency involved in the 
trade (such as US Dollars). CCY] amount 908 specifies an amount of the first 
currency involved in the trade. CCY2 identifier 9 1 0 identifies a second currency 
involved in the trade (such as Japanese Yen). CCY2 amount 912 specifies an amount 
5 of the second currency involved in the trade. Conversion rate 914 specifies a 
conversion rate between the first currency and the second currency. 

CCY1 organization 916 identifies a first organization involved in the trade, 
and CCY1 subsidiary 918 identifies a specific subsidiary of the first organization that 
is involved in the trade. CCY2 organization 920 identifies a second organization 
10 involved in the trade, and CCY2 subsidiary 922 identifies a specific subsidiary of the 
second organization that is involved in the trade. 

CCY1 account 924 identifies and account for the first organization, and CCY1 
custodian 926 identifies an institution (bank) maintaining the account for the first 
organization. CCY2 account 928 identifies and account for the second organization, 
1 5 and CCY2 custodian 930 identifies an institution maintaining the account for the 
second organization. 

There are also trading, settlement and settlement approval signatures for 
currency one, 932, 934 and 935, as well as trading, settlement and settlement approval 
signatures for currency two, 936, 938 and 939. 
20 Note that certain portions of trade record 900 are signed by a user, such as 

front office trader 310, and other portions are signed by a settlement clerk, such as 
settlement clerk 311. In particular, front office trader 310 signs portions of trade 
record 900 that include trade parameters. Settlement clerk 31 1 (and a settlement 
approver) signs these as well as the portions of trade record 900 that contain 
25 settlement instructions, such as account identifiers. (The "1" values in FIG. 9 indicate 
which portions of the trade record are signed by respective entities, the "-" values 
indicate portions which are not signed, and the "S" values indicate the respective 
digital signatures.) 
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Policy Approval Record Structure 

Policy Approval Records are used as a control mechanism for ensuring that 
the proper authorization checks are performed by the system. The policy approval 
records are made up of authorization rules and a set of associated digital signatures 
5 that validate those rules. An initial policy approval record may be bootstrapped into 
the system. This initial record should ideally impose a base restriction that all policy 
approval records must be signed by a minimum of two security officers and the policy 
itself should be signed by the two original exchange security officers (the exchange 
PSO and CSO). This requirement prevents a single individual from perpetrating fraud 
1 0 in the system by relaxing authorization safeguards. 

From this base policy, additional policy approval records can then be defined 
to further configure the system's permission handling functions. For instance, 
policies can be defined to enforce things such as the number of signatures required to 
approve a trade or an amendment. These policies are confirmed against all actions 
15 performed on the system to ensure that the requisite validations have been met. 

Process of Establishing a Policy for Approvals 

FIG. 10 is a flow chart illustrating the process of establishing a policy for 
approvals relating to trades and amendments in accordance with an embodiment of 

20 the present invention. A first security officer for an organization (such as for example 
security officer 3 12 or 3 16) first sets the new policy or amends an existing policy to 
create a new policy (step 1002), and then signs the new policy (step 1004). In order 
to conform to the bootstrapped system policy, which dictates dual signatures for new 
policies, the new policy is,then communicated to a second security officer within the 

25 same organization (step 1006). This second security officer examines the new policy 
(step 1 008). If the new policy properly conforms to established rules for the 
organization, the second security officer signs the new policy and stores it in database 
301, which causes the new policy to come into force (step 1010). Note that by 
requiring at least two security officers within an organization to approve policy 



WO 02/093294 



PCT/US02/13756 



22 

changes, a single security officer is unable to unilaterally change the organization's 
security policy. 

For instance, a Permission Security Officer (PSO) may propose a policy that 
requires two settlement clerks to sign and approve a trade settlement instruction. The 
5 PSO generates a policy approval record defining that rule set and signs the record. 
The PSO must then get a second security officer to agree to sign the rule set in order 
to validate the policy in the system. Once the policy has been defined and validated, 
the system will impose the new dual signature requirement on any new trade 
settlement instructions. 

10 

Entities Involved in the Settlement Process 

FIG. 1 1 illustrates entities involved in the settlement process in accordance 

with an embodiment of the present invention. In this embodiment, the financial 

transaction involves an exchange of currencies between a first party 1101 and a 
1 5 second party 1 1 02. Note that parties 1 1 0 1 and 1 1 02 can include any two parties in a 

foreign exchange transaction, such as parties 202-204 and 208-210 in FIG. 1, or 

parties 302 and 304 in FIG. 3. 

Parties 1 101 and 1 102 first communicate through exchange (CX) 200 to 

establish and sign a trade record with settlement instructions as is discussed above. 
20 Exchange 200 then passes this trade record on to clearing agents 1 1 1 1-1 1 12, who 

communicate through wire services 1 120 (or other communication pathways) to 

actually move funds between accounts to complete the transaction. For example, 

clearing agents may use wire services or payment systems belonging to SWIFT, 

CHIPS, CEDEL, ACH and even VISA to move funds. 
25 Note that the process of authorization and authentication is facilitated by 

certification authority 320 as is discussed above. 



30 



Settlement Process 

FIG. 12 is a flow chart illustrating the settlement process in accordance with 
an embodiment of the present invention. The process starts when a complete and 
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valid trade record 900 is received by CX 200 (step 1202). CX 200 optionally checks 
the signatures of trade record 900 (step 1203) and sends trade record 900 to clearing 
agents 1111 and 1112 along with instructions to move funds for the transaction into 
escrow accounts (or to place holds on the funds in the source accounts) according to 
5 the information in the trade record 900 (step 1204). 

Next, clearing agents 1 1 1 1 and 1 1 12 validate trade record 900 and the 
accompanying instructions using digital signatures as is described above in preceding 
sections of this disclosure (step 1206). 

If trade record 900 and the accompanying instructions are successfully 

10 validated, clearing agents 1 1 1 1 and 1 112 attempt to move funds for the trade into 
escrow accounts (or attempt to place holds on the funds in the source accounts) (step 
1208). If the funds are successfully moved (or if the holds are successfully placed) 
clearing agents 1111 and 1112 indicate this by sending a signed message of success to 
CX 200. If both messages are valid and indicate success, CX 200 instructs clearing 

15 agents 1111 and 1 112 to move funds from the escrow accounts (or source accounts) 
into the destination accounts specified by the settlement instructions (step 1218) by 
forwarding the corresponding signed message of success to each of clearing agents 
1111 and 1112. 

Upon receiving notification of receipt of these instructions from clearing 
20 agents 1 1 1 1 and 1 1 12, CX 200 notifies parties 1 101 and 1 102 that clearing agents 

1111 and 1112 have received the instructions and allows clearing agents 1111 and 

1 1 12 to transfer the funds. Furthermore, upon receiving a "payment done" message 
from clearing agents 1 1 1 1 and 1 1 12, CX 200 commits the transaction to a database 
(step 1220). Note that after clearing agents 1111 and 1 1 12 receive the instructions, 

25 CX 200 is not responsible for ensuring that the funds are transferred. Clearing agents 
1111 and 1112 assume this responsibility. 

Also note that if the funds are successfully moved (or if the holds are 
successfully placed) at step 1210, an "advice of funds" or "advice of credit" 
communication can be sent to parties 1 101 and 1 1 02 to let them know that they 

30 should expect to receive the funds. 
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If the funds are not successfully moved into the escrow accounts (or if holds 
cannot be placed on the funds) in step 1208, the system rolls back the transaction (step 
1212) and reports the failure to parties 1 101 and 1102 as well as clearing agents 1111 
and 1112 (step 1214). The system also retries the transaction if appropriate (step 
5 1216). 

If clearing agents 1111 and 1112 cannot validate the trade record and 
instructions in step 1206, the system reports the failure to parties 1 101 and 1 102 as 
well as clearing agents 1111 and 1 1 12 (step 1214) and retries the transaction if 
appropriate (step 1216). 

10 Note that if the system places holds on the funds in the source accounts rather 

than moving the funds through an escrow account, then it only requires a single wire 
transfer into each destination account rather than two transfers for each destination 
account. However, note that moving the funds through escrow accounts provides 
more assurance that the funds will be available to complete the transaction. 

15 Also note that although the present invention is described in terms of two 

clearing agents 1 1 1 1 and 1 1 12 and two associated escrow accounts, the present 
invention is not meant to be limited to such a configuration. For example, the present 
invention can be applied to systems that use a single clearing agent and a single 
escrow account, such as the Continuous-Linked Settlement (CLS) system. 

20 

Settlement Process with Payment Guarantee 

FIG. 1 3 is a flow chart illustrating the settlement process in accordance with 
an embodiment of the present invention. The process starts when a complete and 
valid trade record 900 is received by CX 200 (step 1302). 

25 In this embodiment, trade record 900 includes payment guarantees from the 

parties 1 101 and 1 102. A payment guarantee can indicate that a hold has been placed 
on the required funds in the source account, or alternatively, a payment guarantee can 
be the payment instrument itself in digital form, such as digital cash. Note that these 
payment guarantees are provided by the parties 1 101-1 102 during the negotiations 

30 which caused trade record 900 to be formed. 
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CX 200 optionally checks the signatures of trade record 900 (step 1303). CX 
200 and sends trade record 900 to clearing agents 1111 and 1 1 12 along with 
instructions to move funds into destination accounts to complete the transaction (step 
1304). 

5 Next, clearing agents 1 1 1 1 and 1 1 12 validate trade record 900 and the 

accompanying instructions using digital signatures (step 1306). 

If trade record 900 and the accompanying instructions are successfully 
validated, CX 200 instructs clearing agents 1 1 1 1 and 1 1 1 2 to move funds for the trade 
into destination accounts according to the information in the trade record 900. 
10 Clearing agents 1 1 1 1 and 1 1 12 then move the funds and send signed 
acknowledgements to CX 200 (step 1308) 

Upon receiving signed notification of receipt and status of these instructions 
from clearing agents 1 1 1 1 and 1 1 12, CX 200 notifies parties 1 101 and 1 102 that 
clearing agents 1111 and 1112 have carried out the instructions by forwarding the 
15 signed receipts, CX 200 also commits the transaction to a database (step 1320). 

If clearing agents 1 1 1 1 and 1 1 12 cannot validate trade record 900 and the 
instructions in step 1306, the system reports the failure to parties 1 101 and 1 102 (step 
1314) and retries the transaction if appropriate (step 1316). 

The foregoing descriptions of embodiments of the present invention have been 
20 presented for purposes of illustration and description only. They are not intended to 
be exhaustive or to limit the present invention to the forms disclosed. Accordingly, 
many modifications and variations will be apparent to practitioners skilled in the art. 
Additionally, the above disclosure is not intended to limit the present invention. The 
scope of the present invention is defined by the appended claims. 



25 
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What Is Claimed Is: 

1 . A method for automatically settling a financial transaction, 
comprising: 

5 receiving a trade record specifying previous ly-agreed-to details of the 

financial transaction between a first party and a second party; 

wherein the trade record includes settlement instructions specifying a first 
transfer of a first financial instrument belonging to the first party into a second party 
destination account belonging to the second party; 
10 wherein the trade record includes a second digital signature created by 

digitally signing at least a portion of the trade record including the settlement 
instructions with a second private key belonging to the second party; 

ensuring that funds are available to complete the financial transaction; and 
if funds are ensured to be available, causing the first transfer of the first 
1 5 financial instrument into the second party destination account on condition that the 
second digital signature can be verified using a corresponding second public key. 

2. The method of claim 1, 

wherein the settlement instructions additionally specify a first party source 
20 account belonging to the first party, from which the first financial instrument is to be 
transferred; and 

wherein the trade record additionally includes a first digital signature created 
by digitally signing at least a portion of the trade record including the settlement 
instructions with a first private key belonging to the first party. 

25 

3. The method of claim I, wherein causing the first transfer involves 
communicating at least a portion of the trade record, including the settlement 
instructions and the second digital signature, to a first clearing agent so that the first 
clearing agent can use the corresponding second public key to verify that the second 
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digital signature was created using the second private key prior to transferring the first 
financial instrument into the second party destination account. 

4. The method of claim I, 

5 wherein the settlement instructions additionally specify a second transfer of a 

second financial instrument to a first party destination account; and 

wherein the trade record includes a first digital signature created by digitally 
signing at least a portion of the trade record including the settlement instructions 
using a first private key belonging to the first party. 

10 

5. The method of claim 4, wherein causing the second transfer involves 
communicating at least a portion of the trade record, including the settlement 
instructions and the first digital signature, to a second clearing agent, so that the 
second clearing agent can use a first public key to verify that the first digital signature 

1 5 was created using the first private key prior to transferring the second financial 
instrument into the first party destination account. 

6. The method of claim 1, wherein ensuring that funds are available to 
complete the financial transaction involves causing the first transfer of the first 

20 financial instrument from the first party into a first escrow account, so that the first 
financial instrument is available to be transferred into the second party destination 
account. 

7. The method of claim 1, 

. 25 wherein the settlement instructions additionally specify a first party source 

account belonging to the first party, from which the first financial instrument is to be 
transferred to the second party destination account; and 

wherein ensuring that funds are available to complete the financial transaction 
involves causing a hold to be placed on the first financial instrument within the first 
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party source account, so that the first financial instrument is ensured to be available to 
be transferred into the second party destination account. 

8. The method of claim 1 , 

5 wherein ensuring funds are available to complete the financial transaction 

involves verifying a payment guarantee contained within the trade record, the 
payment guarantee having been previously provided by the first party; and 

wherein the payment guarantee ensures that the first financial instrument is 
available to be transferred to the second party destination account. 

10 

9. The method of claim 8, wherein the payment guarantee includes a 
record that a hold has been placed on the first financial instrument within a first 
source account belonging to the first party. 

15 10. The method of claim 8, wherein the payment guarantee includes a 

digital form of the first financial instrument. 

1 1 . The method of claim 1 , further comprising recording the settlement 
operation in a database,. 

20 

12. The method of claim 1, further comprising validating an identity of the 
first party by using a public key of a certification authority to verify that a certificate 
containing the public key of the first party was signed by a corresponding private key 
belonging to the certification authority; 

25 wherein the signing by the certification authority indicates that the 

certification authority has verified the identity of the first party. 

13. The method of claim 1, wherein the financial transaction involves 
foreign exchange, and wherein a trade record for the financial transaction includes: 

30 a trade identifier; 
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a trade date; 

an identifier for a first currency; 
a first currency amount; 

an identifier for a first organization providing the first currency; 
an identifier for a second currency; 
a second currency amount; and 

an identifier for a second organization providing the second currency. 

14. A computer-readable storage medium storing instructions that when 
executed by a computer cause the computer to perform a method for automatically 
settling a financial transaction, the method comprising: 

receiving a trade record specifying previously-agreed-to details of the 
financial transaction between a first party and a second party; 

wherein the trade record includes settlement instructions specifying a first 
transfer of a first financial instrument belonging to the first party into a second party 
destination account belonging to the second party; 

wherein the trade record includes a second digital signature created by 
digitally signing at least a portion of the trade record including the settlement 
instructions with a second private key belonging to the second party; 

ensuring that funds are available to complete the financial transaction; and 

if funds are ensured to be available, causing the first transfer of the first 
financial instrument into the second party destination account on condition that the 
second digital signature can be verified using a corresponding second public key. 

15. The computer-readable storage medium of claim 14, 

wherein the settlement instructions additionally specify a first party source 
account belonging to the first party, from which the first financial instrument is to be 
transferred; and 
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wherein the trade record additionally includes a first digital signature created 
by digitally signing at least a portion of the trade record including the settlement 
instructions with a first private key belonging to the first party. 



5 16. The computer-readable storage medium of claim 14, wherein causing 

the first transfer involves communicating at least a portion of the trade record, 
including the settlement instructions and the second digital signature, to a first 
clearing agent so that the first clearing agent can use the corresponding second public 
key to verify that the second digital signature was created using the second private 
1 0 key prior to transferring the first financial instrument into the second party destination 
account. 



1 7. The computer-readable storage medium of claim 14, 
wherein the settlement instructions additionally specify a second transfer of a 
1 5 second financial instrument to a first party destination account; and 

wherein the trade record includes a first digital signature created by digitally 

signing at least a portion of the trade record including the settlement instructions 

using a first private key belonging to the first party. 

20 1 8. The computer-readable storage medium of claim 1 7, wherein causing 

the second transfer involves communicating at least a portion of the trade record, 
including the settlement instructions and the first digital signature, to a second 
clearing agent, so that the second clearing agent can use a first public key to verify 
that the first digital signature was created using the first private key prior to 

25 transferring the second financial instrument into the first party destination account. 



1 9. The computer-readable storage medium of claim 14, wherein ensuring 
that funds are available to complete the financial transaction involves causing the first 
transfer of the first financial instrument from the first party into a first escrow 
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account, so that the first financial instrument is available to be transferred into the 
second party destination account. 

20. The computer-readable storage medium of claim 14, 

5 wherein the settlement instructions additionally specify a first party source 

account belonging to the first party, from which the first financial instrument is to be 
transferred to the second party destination account; and 

wherein ensuring that funds are available to complete the financial transaction 
involves causing a hold to be placed on the first financial instrument within the first 
10 party source account, so that the first financial instrument is ensured to be available to 
be transferred into the second party destination account. 

2 1 . The computer-readable storage medium of claim 1 4, 

wherein ensuring funds are available to complete the financial transaction 
15 involves verifying a payment guarantee contained within the trade record, the 
payment guarantee having been previously provided by the first party; 

wherein the payment guarantee ensures that the first financial instrument is 
available to be transferred to the second party destination account. 

20 22. The computer-readable storage medium of claim 21, wherein the 

payment guarantee includes a record that a hold has been placed on the first financial 
instrument within a first source account belonging to the first party. 

23. The computer-readable storage medium of claim 21, wherein the 
25 payment guarantee includes a digital form of the first financial instrument. 

24. The computer-readable storage medium of claim 14, wherein the 
method further comprises recording the settlement operation in a database. 
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25. The computer-readable storage medium of claim 1 4, wherein the 
method further comprises validating an identity of the first party by using a public key 
of a certification authority to verify that a certificate containing the public key of the 
first party was signed by a corresponding private key belonging to the certification 

5 authority; 

wherein the signing by the certification authority indicates that the 
certification authority has verified the identity of the first party. 

26. The computer-readable storage medium of claim 14, wherein the 
10 financial transaction involves foreign exchange, and wherein a trade record for the 

financial transaction includes: 
a trade identifier; 
a trade date; 

an identifier for a first currency; 
1 5 a first currency amount; 

an identifier for a first organization providing the first currency; 
an identifier for a second currency; 
a second currency amount; and 

an identifier for a second organization providing the second currency. 

20 

27. An apparatus that automatically settles a financial transaction, 
comprising: 

a receiving mechanism that is configured to receive a trade record specifying 
previously-agreed-to details of the financial transaction between a first party and a 
25 second party; 

wherein the trade record includes settlement instructions specifying a first 
transfer of a first financial instrument belonging to the first party into a second party 
destination account belonging to the second party; 
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wherein the trade record includes a second digital signature created by 
digitally signing at least a portion of the trade record including the settlement 
instructions with a second private key belonging to the second party; and 

a transferring mechanism that is configured to, ensure that funds are available 
5 to complete the financial transaction, and if funds are ensured to be available, to cause 
the first transfer of the first financial instrument into the second party destination 
account on condition that the second digital signature can be verified using a 
corresponding second public key. 

10 28. The apparatus of claim 27, 

wherein the settlement instructions additionally specify a first party source 
account belonging to the first party, from which the first financial instrument is to be 
transferred; and 

wherein the trade record additionally includes a first digital signature created 
1 5 by digitally signing at least a portion of the trade record including the settlement 
instructions with a first private key belonging to the first party. 



29. The apparatus of claim 27, wherein the transferring mechanism is 
configured to cause the first transfer by communicating at least a portion of the trade 

20 record, including the settlement instructions and the second digital signature, to a first 
clearing agent so that the first clearing agent can use the corresponding second public 
key to verify that the second digital signature was created using the second private 
key prior to transferring the first financial instrument into the second party destination 
account. 

25 

30. The apparatus of claim 27, 

wherein the settlement instructions additionally specify a second transfer of a 
second financial instrument to a first party destination account; and 
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wherein the trade record includes a first digital signature created by digitally 
signing at least a portion of the trade record including the settlement instructions 
using a first private key belonging to the first party. 

5 31. The apparatus of claim 30, wherein the transferring mechanism is 

configured to cause the second transfer by communicating at least a portion of the 
trade record, including the settlement instructions and the first digital signature, to a 
second clearing agent, so that the second clearing agent can use a first public key to 
verify that the first digital signature was created using the first private key prior to 
10 transferring the second financial instrument into the first party destination account. 

32. The apparatus of claim 27, wherein the transferring mechanism is 
configured to ensure that funds are available to complete the financial transaction by 
causing the first transfer of the first financial instrument from the first party into a first 

1 5 escrow account, so that the first financial instrument is available to be transferred into 
the second party destination account. 

33. The apparatus of claim 27, 

wherein the settlement instructions additionally specify a first party source 
20 account belonging to the first party, from which the first financial instrument is to be 
transferred to the second party destination account; and 

wherein the transferring mechanism is configured to ensure that funds are 
available to complete the financial transaction by causing a hold to be placed on the 
first financial instrument within the first party source account, so that the first 
25 financial instrument is ensured to be available to be transferred into the second party 
destination account. 



30 



34. The apparatus of claim 27, 

wherein the transferring mechanism is configured to ensure that funds are 
available to complete the financial transaction by verifying a payment guarantee 
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contained within the trade record, the payment guarantee having been previously 
provided by the first party; and 

wherein the payment guarantee ensures that the first financial instrument is 
available to be transferred to the second party destination account. 

5 

35. The apparatus of claim 34, wherein the payment guarantee includes a 
record that a hold has been placed on the first financial instrument within a first 
source account belonging to the first party. 

10 36. The apparatus of claim 34, wherein the payment guarantee includes a 

digital form of the first financial instrument. 

37. The apparatus of claim 27, further comprising a recording mechanism 
that is configured to record the settlement operation in a database. 

15 

38. The apparatus of claim 27, further comprising a validation mechanism 
that is configured to validate an identity of the first party by using a public key of a 
certification authority to verify that a certificate containing the public key of the first 
party was signed by a corresponding private key belonging to the certification 

20 authority; 

wherein the signing by the certification authority indicates that the 
certification authority has verified the identity of the first party. 

39. The apparatus of claim 27, wherein the financial transaction involves 
25 foreign exchange, and wherein a trade record for the financial transaction includes: 

a trade identifier; 
a trade date; 

an identifier for a first currency; 
a first currency amount; 
30 an identifier for a first organization providing the first currency; 
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an identifier for a second currency; 
a second currency amount; and 

an identifier for a second organization providing the second currency. 
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